Subject: Revised Flow Control Proposal

From: "Shannon Nix" <[email-masked]>
Date: Fri, 29 Apr 94 16:57:09

Hello,

As promised, Metaplex is issueing a modified flow control proposal based 
on the latest proposal submitted by Peter Gayek of IBM.  The requirement
to be addressed was to allow the receiving implementation some feedback
on how well the pacing window was being utilized.

The base proposal is  available on ibmstandards.cary.ibm.com in 
aiw/dlsw/flowcontrol/pacing-0.txt).

Our modified proposal is an edit of that file in the same path in
pacing-1.txt.

Sorry for the delay, but we were exploring a number of alternatives.  This 
proposal was chosen because:

1. It fit well with the existing proposal (minimal changes)
2. It satisfied the requirement of allowing the receiving implementation
   to receive some feedback on whether the current pacing window is being
   utilized.

I will describe the CHANGES to the base proposal in this mail and discuss the
rationale for said changes.

*******  PROPOSED CHANGES TO BASE PROPOSAL

1.  When a sender receives a pacing response, the new window REPLACES
    any residual portion of the previous window.  Therefore the next
    frame sent by the sender must contain the PREQ bit.  The size of the
    new window is indicated by f(previous_size, IWI, DWI, HWI, RWI).   
    
    The base proposal states that the new window was ADDED to the residual of 
    the previous window.
    
2.  A new bit (or bit combination) shall be introduced in the header:

    DWI - Decrement Window Indicator
    
    It shall cause the new window to be the size of the previous window
    minus one.  If the previous window was one, then this shall be treated
    the same as the RWI bit.
    
3.  At circuit-startup time, the current window size shall be the size 
    negotiated in the capabilities exchange.  HOWEVER, the sender's initial
    state shall be:
    
    S: I have exhausted my current window and am waiting for a PRSP
    
    The receiver's initial state shall be:
    
    R: I owe the sender a PRSP and he has no outstanding buffers in the
       current window.
    
******** RATIONALE FOR CHANGES

1. Making the new window replace the residual portion of the old window
   allows the receiver to discern when the sender has used all of the
   window which he was granted.  When this condition occurs, then the receiver
   can assert that there was an interval during which, if the sender had data
   to send, he would have been forced to wait on a PRSP.  This condition
   is illustrated by the following flow diagram:

   SENDER               RECEIVER
   -----------------------------
   ... (window size is N)
   DATA+PREQ------------------->        
                  o---------PRSP
   DATA-----------+------------>
   ...            |
   DATA (last in window - Nth)->
                  |
   <--------------o
   DATA+PREQ------------------->
   
   If the condition NEVER occurs, then there is NO reason for the
   receiver to increment the window size.
   
   If, however, the condition DOES occur, the the receiving implementation
   could find the frequency (or relative frequency) of its occurences
   as useful input in determining the next window size.
   
   NOTE1: The receiver is not required to use the information in ANY fashion.
   
   NOTE2: The receiver is not required to respond to a PREQ immediately
          (wasn't in the original proposal either).
          
2. DWI was introduced to allow a more useful steady-state downward adjustment
   to the pacing window.  HWI is just too coarse for that purpose.          
   
3. The initial state restrictions were introduced so that the receiver
   can maintain deterministic control over his resources.  Otherwise,
   an implicit initial window size compounded by as flurry of new sessions
   when resources are critical can cause the receiver to be overcommitted 
   simply by allowing new sessions to start up.
   
   VARIATION:  Forget initial window size in CAPEX and both sides come
   up with the window size reset to zero. The sender would begin by sending
   the PREQ+RWI IPM.

Regards,
Shannon

---

From: Bill Kwan <[email-masked]>
Date: Mon, 02 May 94 20:08:45 EST

Shannon,

Good idea. Looks like it should work. However, I do have one issue on a 
potential side-effect.

Historically, all pacing in SNA is cumulative (not reset/replace as in your 
updated proposal). The rationale has been that a reset pacing scheme can 
create excessive supervisory traffic (i.e., isolated pacing responses) 
during periods of low-session traffic. This occurs because most 
implementations (usually due to the fact that it is the easiest) will 
respond right away when it receives a pacing request (unless it is 
congested). If the pacing window of the sender was reset to the window 
size, then his next request will again have the pacing request on. This
causes every data to require a pacing response (i.e., the effective window
is actually smaller).

I don't know how serious a problem this is in reality, but one way that might 
help may be to not have the receiver respond to the pacing request right 
away. It should wait for some function of the window size (half ?). Right 
now, the description says it is implementation dependent when the pacing 
response is sent back.

The initial state of having the sender window reset and waiting for a PRSP
is reasonable. That is the way Virtual Route pacing works and for the same
rationale.

Regards,
Bill

______________________________ Reply Separator _________________________________
Subject: Revised Flow Control Proposal
Author:  [email-masked] at inet
Date:    4/29/94 4:57 PM

Hello,

   SENDER               RECEIVER

Regards,
Shannon

---

From: "Shannon Nix" <[email-masked]>
Date: Tue, 03 May 94 11:06:08

Hi Bill,
     
     Thanks for your comments.
     
     Your absolutely right about the "side-effect".  We considered this and 
     as you pointed out, there are some options that the receiver has to 
     smooth this effect.  However we considered these receiver 
     implementation issues.
     
     Since on circuits with sporadic traffic this degenerates to "definite 
     response mode", do we want to specify some receiver options to smooth 
     this effect or do we wish to leave it to the discretion of the 
     implementor?  What does everyone think?
     
     Regards, Shannon

______________________________ Reply Separator _________________________________
Subject: Re: Revised Flow Control Proposal
Author:  Bill Kwan <[email-masked]> at 
Internet-Gateway
Date:    5/2/94 8:08 PM

Shannon,

     
I don't know how serious a problem this is in reality, but one way that might 
help may be to not have the receiver respond to the pacing request right away. 
It should wait for some function of the window size (half ?). Right now, the 
description says it is implementation dependent when the pacing response is 
sent back.

Regards,
Bill

     <deleted>

---

From: Bill Kwan <[email-masked]>
Date: Tue, 17 May 94 11:57:06 EST

Shannon,
     
     I tend to agree with you. Since the sending of a PRSP is also tied to 
     congestion on the receiver, it is probably better to leave it as 
     implementation dependent. However, I think a description of the issue
     should be added to the specification, so implementers are aware of
     this potential situation. As we get more implementation experience, we
     can revisit this issue later.
     
     Having said that, I am still not too comfortable with the concept of 
     using a non-cumulative pacing. This is probably because I am so used to
     SNA pacing that I am "brainwashed" into thinking that way.
     
     I would feel a lot more comfortable, if someone who has worked on the
     flow control in SNA (from IBM?) to comment on us using a non-cumulative
     pacing scheme. They may have some additional insight and data (maybe
     even comparing the effects of the two types of pacing). I just don't
     want us to trade one benefit (sender feedback) for a different set of 
     problems.

     Regards,
     Bill
     
______________________________ Reply Separator _________________________________
Subject: Re[2]: Revised Flow Control Proposal
Author:  [email-masked] at inet
Date:    5/3/94 11:06 AM

     Hi Bill,

     Regards, Shannon

Shannon,

Regards,
Bill

     <deleted>